(о формате данных)

comput. (представлении) Datenkonvention (напр. о формате данных)

 

уровень представления данных
уровень представления
Ндп. представительный уровень
Уровень взаимосвязи открытых систем, обеспечивающий услуги по обмену данными между логическими объектами прикладного уровня, преобразование и представление данных в нужном формате.
[ ГОСТ 24402-88]

Недопустимые, нерекомендуемые

• представительный уровень

Тематики

• телеобработка данных и вычислительные сети

Синонимы

• уровень представления

EN

• presentation layer

30. Уровень представления данных

Уровень представления

Ндп. Представительный уровень

Presentation layer

Уровень взаимосвязи открытых систем, обеспечивающий услуги по обмену данными между логическими объектами прикладного уровня, преобразование и представление данных в нужном формате

Источник: ГОСТ 24402-88: Телеобработка данных и вычислительные сети. Термины и определения оригинал документа

4.13 преобразование биометрических данных (biometric transformation): Преобразование ЗБИ, представленной в исходном формате ведущей организации ЕСФОБД, в ЗБИ, представляемую в целевом формате ведущей организации ЕСФОБД.

Примечание - Данное преобразование может включать в себя обработку содержимого ББД (6.5.11 и 6.5.14).

Источник: ГОСТ Р ИСО/МЭК 19785-1-2008: Автоматическая идентификация. Идентификация биометрическая. Единая структура форматов обмена биометрическими данными. Часть 1. Спецификация элементов данных оригинал документа

 

реляционная база данных
База данных, реализованная в соответствии с реляционной моделью данных.
[ ГОСТ 20886-85]

реляционная БД
База данных, логически организованная в виде набора отношений ее компонентов.
Характерной особенностью реляционной базы данных является структура, выполненная в виде таблиц. Строки таких таблиц соответствуют записям, столбцы - атрибутам (признакам хранимых данных). Например, таблица, в которой имеются столбцы: фамилия, год рождения, место работы, домашний адрес, телефон, а в строках записываются эти сведения о сотрудниках предприятия. Такие данные являются ядром реляционной базы.
Использование реляционных баз данных позволяет:
собирать и хранить данные в виде таблиц;
обновлять их содержание;
получать разнообразную информацию по атрибутам или записям;
отображать полученные данные в виде диаграмм или таблиц;
выполнять необходимые расчеты по материалам базы.
(Терминологическая база данных по информатике и бизнесу [Электронный ресурс])
[ http://www.morepc.ru/dict/]

Системы управления реляционными базами данных

Процесс отделения программ от структур данных завершили, в конечном итоге, реляционные базы данных (РБД).

В РБД все данные представлены исключительно в формате таблиц, или, по терминологии реляционной алгебры, отношений (relation). Таблица в реляционной алгебре - это неупорядоченное множество записей (строк), состоящих из одинакового набора полей (столбцов). Каждая строка характеризует некий объект, каждый столбец - одну из его характеристик. Совокупность таких связанных таблиц и составляет БД, при этом таблицы полностью равноправны - между ними не существует никакой иерархии. Реляционная модель является простейшей и наиболее привычной формой представления данных.

Можно было бы привести более строгое определение, но это не является пред-метом настоящей статьи. Здесь нам важно отметить следующее. РБД позволили моделям данных отражать взаимосвязи прикладной области, а не методы программного доступа к данным и структурам данных. Это огромный шаг вперед по нескольким причинам:

Отражающие прикладную область знаний модели данных являются интуитивно понятными конечному пользователю.

Реорганизация данных на физическом уровне совершенно не влияет на выпол-нение прикладных программ. Одним из важнейших побочных эффектов данного преимущества является появление клиент-серверных архитектур, сохраняющих все достоинства централизованного администрирования и управления данными, с одной стороны, и дружески настроенных по отношению к пользователю клиентских программ, с другой. Благодаря нормализации удается избежать чрезмерного дублирования данных.

По идее, с точки зрения быстродействия, реляционные СУБД должны проигры-вать сетевым и иерархическим моделям. Однако специальные методы, в частности, индексирование БД, позволяют поддерживать их скоростные характеристики на достаточно высоком уровне.

Развитие РБД

По мере все более широкого распространения реляционных моделей данных крупные поставщики БД расширяли функциональные возможности, повышали производительность в борьбе за место на рынке. В качестве примеров новых функций можно привести следующее:

• Хранимые процедуры
  Откомпилированные последовательности SQL-операторов, которые хранятся в БД. Хранимые процедуры исполняются быстрее обычных SQL-операторов, уменьшают объем сетевого трафика и скрывают сложность SQL-выражений от конечного пользователя.

• Триггеры
  Последовательности SQL-операторов, автоматически запускаемые сервером при возникновении определенных, связанных с данными событий. Обычно они используются для поддержания целостности данных и выполнения таких, связанных с модификацией данных, операций, как трассировка (распечатка программой связанных с ее выполнением событий) и аудирование (ведение журнала событий с целью обеспечения безопасности вычислительной системы.).
   
• Дублирование и рассредоточение.
  Довольно часто с целью повышения произво-дительности, безопасности и готовности информации приходится дублировать данные на удаленных БД. Например, дублировать хранящуюся на удаленном сервере итоговую производственную информацию в центральной БД.
   
• Взаимодействие с другими системами.
  После того, как электронная почта приобрела широкую популярность, поставщики БД разработали интерфейс, позволяющий посылать определенные почтовые сообщения в момент возникновения определенных, связанных с операциями над данными, событиями.

[ http://www.rtsoft-training.ru/?p=600017]

Тематики

• базы данных

Синонимы

• РБД
• реляционная БД

EN

• RDB
• relational data base
• Relational Database

 

запись данных о начислении платы
Совокупность информации о подлежащем оплате событии, представленная в определенном формате (например, время установления соединения, длительность вызова, объем передаваемых данных и др.), предназначенная для использования при составлении счетов и учете. (МСЭ-Т Q.1741).
[ http://www.iks-media.ru/glossary/index.html?glossid=2400324]

Тематики

• электросвязь, основные понятия

EN

• charging data record
• CDR

 

аварийное сообщение в формате для КПК
-
[Интент]

Тематики

• ЦОДы (центры обработки данных)

EN

• PDA-formatted alert

IT. (данных) normale Ausgabe

comput. Formatabsprache (данных)

IT. Formvorschriften (данных)

 

протокол управления простой сетью
Протокол, управляющий сетью, сетевыми устройствами и их функциями.
[Е.С.Алексеев, А.А.Мячев. Англо-русский толковый словарь по системотехнике ЭВМ. Москва 1993]

простой протокол сетевого управления
Прикладной протокол (L7) управления сетевыми устройствами. Основное предназначение состоит в получении подробной информации о состоянии устройства и изменении его конфигурации в автоматическом режиме. Помимо периодического считывания SNMP-сервером информации с устройства, возможна активная сигнализация самим устройством о произошедших событиях.
[ http://www.morepc.ru/dict/]

простой протокол управления сетью
Протокол группы IETF по управлению сетью. Основной протокол администрирования сетей TCP/IP, обеспечивающий мониторинг и контроль сетевых устройств, обслуживание их конфигураций, сбор статистических данных, замеры производительности и проверку безопасности (МСЭ-Т Х.805; МСЭ-Т J.116).
[ http://www.iks-media.ru/glossary/index.html?glossid=2400324]

Вопросы сетевого управления традиционно входят в число основных как для производителей программ и оборудования, так и для организаций, занимающихся разработкой стандартов. Невероятно высокий темп развития сетей на базе протокола TCP/IP (и Internet в частности) и движение в сторону создания единой информационной магистрали обусловили необходимость разработки стандартного протокола управления устройствами по сети и множества высокоуровневых продуктов, которые его используют.

Протокол управления сетями определяет стандартный метод контроля какого-либо устройства со станции управления с целью определения его состояния, настроек и иной информации, а также ее модификации. Основным протоколом управления, используемым в семействе TCP/IP, является протокол SNMP (Simple Network Management Protocol простой протокол управления сетью). Сам протокол очень прост: он определяет только иерархическое пространство имен объектов управления и способ чтения (или записи) данных этих объектов на каждом узле. Основное преимущество этого протокола заключается в том, что он позволяет единообразным образом управлять всеми типами аппаратных средств, независимо от их назначения и особенностей. Все они говорят на одном языке и могут опрашиваться и конфигурироваться с центральной станции.

Однако, SNMP не более чем протокол, поддерживающий диалог двух сторон. Для его использования необходимы две составляющие: программа-агент, работающая на сетевом устройстве, и программа-менеджер, позволяющая дистанционно отслеживать и управлять сетевыми устройствами. Способ ведения диалога между агентом и менеджером показан на рис.1.

Рис. 1 Работа протокола SNMP в рамках модели OSI

Протокол SNMP традиционно используется для управления телекоммуникационным оборудованием. Для управления обычно применяются так называемые платформы сетевого управления, позволяющие осуществлять обнаружение устройств в сети, объединять модули управления оборудованием разных производителей, выполнять общие функции управления и оповещения. В число наиболее известных платформ сетевого управления входят HP OpenView (Hewlett-Packard), Solstice Domain Manager (Sun Microsystems), Tivoli NetView (Tivoli Systems), SNMPc (Castle Rock). Вместе с тем, управление с использованием SNMP может быть применено и для решения других задач в том числе для систем промышленного управления. Проиллюстрируем такой подход на реальном примере.

В ходе выполнения одного из экспортных контрактов корпорацией Стинс Коман была разработана, произведена и установлена на ТЭС Фалай (Вьетнам) система управления электрофильтром. Логически система была разделена на два уровня: нижний монтируемый в непосредственной близости от электрофильтра, и верхний осуществляющий сбор статистической информации и представляющий графически состояние всего объекта. От использования существующих SCADA-систем мы отказались из-за высокой стоимости пакета разработки и модулей времени выполнения, а также большого времени, необходимого на обучение разработчиков. Было решено пойти по пути собственной разработки. Связь между подсистемами верхнего и нижнего уровней была осуществлена традиционными для задач АСУ ТП методами. Из огромного количества используемых полевых протоколов был выбран один, наиболее подходящий по быстродействию и простоте реализации. Учитывая особенности этого протокола, был разработан программный комплекс, осуществляющий сбор информации, анализирующий статистику и графически представляющий состояние управляемого устройства.

Приступив к аналогичным работам по следующему контракту, мы постарались учесть уроки предыдущей разработки и при создании системы управления технологическими процессами воспользоваться нашим опытом проектирования больших сетевых комплексов. В новом варианте системы связь между уровнями осуществлялась по протоколу SNMP. В качестве программы верхнего уровня использовался описанный ниже универсальный SNMP-менеджер.

Использование принципов сетевого управления при создании систем управления технологическими процессами позволило избежать проблем, связанных с интеграцией различных уровней системы. Появился единый универсальный способ управления любым оборудованием, начиная от сетевого маршрутизатора и заканчивая электрофильтром. Для того чтобы появилась возможность управлять устройствами, которые ранее в принципе не подключались к сети, был разработан универсальный программно-аппаратный SNMP-агент eSCape. Это устройство построено на основе однокристального RISC-контроллера и для подключения к сети (локальной или территориально-распределенной) использует Ethernet или PPP. Оно обладает малым весом и невысокой стоимостью и предоставляет широкий выбор вариантов сопряжения с управляемым объектом.

При разработке системы промышленного управления, реализованной в виде SNMP-менеджера, изначально были сформулированы следующие требования:

• новый программный продукт должен обеспечивать сбор и хранение статистических данных, которые должны легко импортироваться в другие программы; 
• новый программный продукт должен работать как под управлением ОС MS Windows 9x/NT/2000, так и под управлением ОС Linux;
• новый программный продукт должен обеспечивать достаточное быстродействие на машинах бюджетного класса;
• для разработки программ рекомендуется использовать свободно распространяемые продукты с открытым исходным кодом.

В результате был разработан программный комплекс EscView, архитектура которого приведена на рис.2.

Рис.2 Программный комплекс, осуществляющий сбор информации, анализ статистики и графическое представление состояния управляемого устройства

Каждому управляемому устройству соответствует SNMP-агент, который может быть встроенным или внешним. SNMP-агенты, подключенные к сети протокола TCP/IP, периодически опрашиваются программой-монитором, которая написана на языке Perl. Периодичность и частота опроса, а также перечень интересующих SNMP-агентов записаны в базе данных, построенной на пакете программ MySQL. Все переменные, считанные в процессе опроса, сохраняются в базе данных. SNMP-агент может также сам проинформировать систему управления о том или ином изменении своего состояния. Для подачи команд устройствам необходимо изменить соответствующие поля базы данных. Все изменения, произошедшие в базе данных, адресно передаются SNMP-агентам.

Рис.3 Пример диалога с пользователем в формате HTML-страницы

Для реализации графического интерфейса пользователя используется HTTP-сервер Apache. Программа, написанная на языке Perl, поддерживает диалоги с пользователем и при помощи базы данных динамически формирует ответ в формате HTML-страницы или в формате WML-страницы.

Страницы HTML предназначены для пользователей, работающих с любым Internet-браузером (например, MS Internet Explorer или Netscape Navigator). Пример реального диалога представлен на рис.3. Страницы WML предназначены для мобильных устройств, поддерживающих протокол WAP (таким устройством может быть сотовый телефон). Для поддержки WAP-клиентов никаких специальных аппаратных доработок производить не надо: в качестве шлюза выступают ресурсы, штатно предоставляемые сотовыми операторами. Соединение между сотовым шлюзом и SNMP-менеджером осуществляется через Internet.

Данное решение может функционировать как под управлением ОС MS Windows 9x/NT/2000, так и под управлением ОС UNIX/Linux. Все программные продукты, используемые при разработке, распространяются свободно.

Описываемое решение уже используется для обслуживания мощных источников бесперебойного питания. В настоящее время на базе этого решения разрабатывается комплекс программ, предназначенных для управления электрофильтром. Оно, в частности, может использоваться для создания интеллектуальных зданий, для распределенного сбора информации с датчиков, а также для реализации заданного промышленного управления через типовые объединённые сети.

[ http://www.mka.ru/?p=40138]

Тематики

• сети вычислительные

Действия

• простой протокол сетевого управления

Синонимы

• простой протокол сетевого управления

EN

• Simple Network Management Protocol
• SNMP

 

язык описания конфигурации системы
Данный язык обеспечивает возможность обмена информацией о конфигурации устройств в стандартизованном формате между программным обеспечением различных фирм-производителей.
[Новости Электротехники №3(75). Релейная защита. МЭК 61850]

Все параметры устройств в части коммуникаций по протоколам стандарта МЭК 61850 должны описываться файлами конфигурации на языке SCL (System Configuration description Language — язык описания конфигурации системы). Вторая редакция стандарта МЭК 61850-6 регламентирует использование следующих видов файлов:

• ICD (IED Capabilities Description) — файл описания возможностей устройства.
  В файле ICD описываются все логические устройства, логические узлы, элементы и атрибуты данных. Кроме того, описываются предварительно сконфигурированные наборы данные (Dataset), блоки управления отправкой GOOSE-сообщений (GOOSE Control Block), отчётов (Report Control Block), мгновенных значений (SV Control Block). Файл ICD обязательно включает два раздела SCL-файла: < IED> и < DataTypeTemplates>. В файле ICD имя устройства обозначается как «TEMPLATE» («Шаблон»).
• IID (Instantained IED Description) — файл описания предварительно сконфигурированного устройства.
  Файлы такого формата используются для передачи в ПО для конфигурирования системы конфигурации отдельного устройства в том случае, если эта конфигурация была создана заранее при помощи ПО для конфигурирования отдельного устройства. Использование файлов IID требуется в том случае, если информационная модель устройства (например, состав логических узлов) зависит от конкретной реализации в проекте.
• SSD (System Specification Description) — файл описания спецификации системы.
  Данный тип файлов описывает в формате языка SCL все элементы подстанции (первичное оборудование и соединения), все функции вторичных систем (в виде логических узлов), а также может описывать привязку функций к первичным устройствам. В том случае, если сами устройства ещё не выбраны, логические узлы в файле SSD не будут привязаны к конкретным устройствам. Тем не менее, в том случае, если ряд устройств уже выбран, то файл SSD также может включать и разделы описания устройств — < IED>, а также раздел коммуникаций — < Communications>.
• SCD (Substation Configuration Description) — файл описания конфигурации подстанции.
  Файл описания конфигурации подстанции используется для передачи данных конфигурации из ПО для конфигурирования системы в ПО для параметрирования отдельных устройств. Данный тип файла содержит полное описание конфигурации как самой подстанции, так и всех коммуникаций, реализуемых в рамках подстанции. В данном файле будут присутствовать все разделы: < Substation>, < Communications>, < IED> (отдельный для каждого устройства), < DataTypeTemplates>. Причём, для каждого GOOSE-сообщения или потока SV в разделе < Communications> будет содержаться описание его коммуникационных параметров (таких как: MAC-Address, VLAN-ID, VLAN-Priority и другие).
• CID (Configured IED Description) — файл описания конфигурации устройства.
  Файл конфигурации, передаваемый из ПО для конфигурирования устройств, непосредственно в само устройство. Этот файл полностью описывает конфигурацию данного устройства в части коммуникаций и фактически представляет собой «урезанный» SCD-файл.

Из представленного выше перечня описание GOOSE- и SV Control блоков могут содержаться во всех файлах, однако полное описание потоков обычно содержится только в файлах формата SCD, CID.

Следует также отметить, что говоря об описании потоков речь в первую очередь идёт об отправке («публикации») данных в формате многоадресных сообщений. Глава 6 стандарта МЭК 61850 также описывает и синтаксис для описания «подписки» на GOOSE-сообщения и SV-потоки, однако, практика работы с терминалами различных производителей показывает, что на сегодняшний день лишь немногие из них используют стандартизованный синтаксис для этих целей.

Ниже приведен фрагмент CID-файла с описанием набора данных (< Dataset>), блока управления отправкой GOOSE-сообщения (< GSEControl>) и описанием коммуникационных параметров для данного GOOSE-сообщения (< GSE> в разделе < Communications>), созданный при помощи ПО для конфигурирования систем Atlan на базе ICD-файла, предоставленного производителем устройства.

[ http://digitalsubstation.ru/blog/2013/04/09/kak-opisy-vaetsya-otpravka-i-priyom-goose-soo/]

Тематики

• релейная защита

EN

• SCL
• system configuration description language